Electronic mail (“e-mail”) has become increasingly popular as a form of communication in today's society. This is due at least in part to the popularity of the Internet. Users of e-mail may be referred to as “users.” The user is generally referred to as a “recipient” when receiving e-mail and as a “sender” when sending e-mail to a recipient. The term “correspondent” may be used to refer to a person or persons who are sending e-mail to, or receiving e-mail from, the user in question.
To send e-mail over a communications network, a user must address an e-mail message to an intended recipient. For example, referring to FIG. 1A, a conventional e-mail address as used on the Internet is illustrated. The address usually has two parts, the user name 100 (also referred to as the “mailbox name”) and the host (or domain) name 102. These two parts are part of a hierarchy of names; that is, the domain name 102 is of a higher level than the user name 100. The user name 100 may be described as the lowest-level name in the hierarchy. Typically, the user name 100 and the host name 102 may be separated by an “at” sign, “@”, 104. To send e-mail over the Internet, the user addresses the e-mail message by placing the intended recipients' addresses in the “To” line (or field) of the message as is well know in the art. In addition, a user may “carbon copy” or “cc” (or “Cc”) yet another intended recipient of the e-mail message by placing that recipient's address in the cc line (or field) as is also well known in the art. There is also typically a “from” line (or field) indicating who sent the message. All of these items together with non-address portions such as subject, date, etc., form what is known as a “header” of the e-mail message. Other options, also well known in the art, are available for various ways to address intended recipients of Internet e-mail. Analogous methods exist for addressing e-mail over other networks.
Unfortunately, as with other forms of communication, for example regular mail and facsimile, users of e-mail may receive a quantity of unwanted or “junk” mail. This may be in the form of “telemarketing” type e-mail (for example an advertisement or a survey). While this may only rise to the level of a mere nuisance or annoyance, in some situations, unwanted e-mail may actually rise to the level of harassment. For example, the user may receive unwanted offensive or obscene e-mail. A malicious e-mail sender could also possibly send “hate mail”.
This type of activity, in some circumstances, may as a practical matter render the user's e-mail capabilities useless. For example, if a malicious e-mail sender barraged the e-mail user's mail box with a multitude of messages that the user would have to review, any wanted, or “non-junk” mail would be buried in a large amount of useless junk e-mail. The malicious e-mail sender could also send messages that were known to offend the recipient so that the recipient would not want to review any of the messages received, including legitimate messages.
The commercialization of the Internet further threatens the usefulness of e-mail. Today, it is easier than in the past to collect address lists and inexpensive to mass distribute messages. Every time a user sends a message to a public newsgroup or list, fills out a Web form, or mails in a product registration card, the server inexpensively obtains an e-mail address and typically some indication of the user's interests. This information can then be sold to marketing firms who can easily automate unsolicited mass e-mailings of advertisements, surveys, and other annoyances that may cost the user connect time and, possibly worse, valuable attention span.
It is desirable to be capable of restricting the receipt of unwanted e-mail and other types of messages sent over a network. In addition, when unwanted e-mail (or messages) is received, it is beneficial to be able to determine in what manner the sender of the unwanted e-mail obtained the user's address.
In U.S. Pat. No. 5,930,479 (“the '479 patent”), issued Jul. 27, 1999, the disclosure of which is hereby incorporated by reference in its entirety herein, I disclose a method and system for sending messages utilizing “channelized addresses” to create different “channels” that correspondents can use to send e-mail to the user. In other words, each user's e-mail account is made accessible via a user-controlled set of channels. Each channel has a distinct structured e-mail address that contains within it the account name and a “channel identifier.” Each legitimate correspondent is allowed to know one or more of these access addresses or channel identifiers.
The system described in the '479 patent allows the user to reject any e-mail not arriving on a proper channel (with a proper channelized address). If unwanted e-mail does arrive on a valid channel, the user may turn the channel off and allow legitimate users of that channel to use another channel. In other words, legitimate users are “switched” to another channel.
The user (or account owner) is provided simple controls for opening a new channel, closing a channel (hence possibly retracting one or more correspondent's access privilege), and switching a channel (notifying selected correspondents that the current channel is being closed, but a new one is open for their use). This can be provided through an automated personal channel agent or administrator (“PCA”). The PCA also causes the received channelized e-mail to look and feel to the user exactly like conventional e-mail. The PCA provides various administrative controls. The PCA manages a database that maps a correspondent's address to its assigned channel, as well as (when applicable) the channel assigned by the correspondent to the account owner.
Referring to FIG. 1B, a “channelized address” 106 according to a preferred embodiment is shown. This address is in the standard Internet domain name format. This format usually consists of a hierarchy of names, the domain name being of a higher level and the user name being of a lower level in the hierarchy.
The channelized address 106 in FIG. 1B comprises at least three basic parts, the user name 108, the channel identifier (or channel ID) 110, and the host (or domain) name 112. Between the channel ID 110 and the host name 112 is an “at” sign, “@”, 104. As shown in FIG. 1B, there is a hyphen (“-”) immediately before and immediately after the channel ID 110. By comparison of FIG. 1A with FIG. 1B, it should be noticed that the conventional address (FIG. 1A) is somewhat similar in appearance to the channelized address (FIG. 1B), except that the channelized address contains the channel ID 110 to the left of the “at” sign 104. Thus, the channelized address 106 contains both traditional address information (e.g., user name 108 and host name 112), as well as the channel ID 110.
The channel ID includes a security string that is practically unguessable (or even random) even when a malicious email sender (or adversary) is aware of several of the user's other preexisting channel identifiers. That is, the channel identifier should be unpredictable by an adversary. The security string may be generated pseudorandomly, may be generated randomly or may be selected by a user. The important point is that the security string be practically unguessable by an adversary, no matter how it is generated.
The administration of the channelized addresses 106 and the generation of the channel ID 110 are accomplished by the PCA, which is described below in more detail with respect to other functions it performs.
A user of the system described in the '479 patent may allocate a number of the channelized addresses 106 having differing channel identifiers 110 for different correspondents. Other than the channel ID portion of the channelized address, the address may look the same for all correspondents. If a correspondent desires to send e-mail to the user, the correspondent must send the e-mail identifying the correct channel; that is, by using an open (or active) channelized address 106 with the proper channel identifier 110. If the correspondent sends to a channel that has not been opened or that has been closed as is described below, the e-mail from the correspondent will be rejected by the user's mail server and the user will never receive it. A goal is thus to control access to a user's mailbox by potential correspondents, not to ensure anonymity of the account owner/user, or to guarantee privacy of the messages.
FIG. 2 illustrates the architecture of the system described in the '479 patent. The hardware involved is connected to a network 200, such as the Internet, for sending e-mail to correspondents and receiving e-mail from correspondents. Connected to the network 200 is a mail server 202. The server 202 is connected to a personal channel agent host (“PCA host”) 204, which is a computer that acts as a host machine for the personal channel agent (“PCA”) 214. The PCA host 204 is connected to a user machine 206. The user machine acts as the user interface to the network 200 for sending and receiving e-mail.
Within the mail server 202 is a mail receiver 208 and a mail sender 210. The mail receiver 208 and mail sender 210 can be implemented using a modified form of the Unix “Sendmail” program. In particular, the Sendmail program is modified to reject messages addressed to closed channels. The mail receiver 208 is a “daemon” program. In other words, the mail receiver 208 constantly checks to determine whether any mail has arrived from the network 200. Preferably, the mail receiver 208 receives e-mail from the network 200 on path 220 using the Simple Mail Transfer Protocol (“SMTP”), although other conventional formats could also be used. The mail sender 210 preferably sends mail to the network 200 on the path 222 using the SMTP protocol, although other conventional formats could also be used. In the SMTP protocol, a message is transmitted with an envelope that specifies the sender and the recipient(s). The message itself comprises header lines (to, from, cc, subject, date, etc.) followed by a blank line followed by the body of the message. The server 202 also contains a channels file 212. The term “file,” as used throughout this disclosure, shall include data and dabases stored on permanent or semipermanent media such as a disk, a tape or a ROM device, and shall also include data and databases resident in transient memory.
Within the PCA host 204 is the PCA 214. The PCA 214 receives mail from the mail receiver 208 via path 216. The PCA 214 is configured to periodically check the mail server 202 for new e-mail. Path 216 preferably uses the POP3 protocol to transfer the e-mail from the mail receiver 208 to the PCA 214. The POP3 protocol is enabled by running a software product, such as “POPPER” (which can be obtained from the Internet at ftp.CC.berkeley.edu) on the mail server 202. Other known implementations of the POP3 protocol, as well as other known protocols, could also be used. The PCA 214 also forwards e-mail to the mail sender 210 via path 218. Path 218 preferably uses the SMTP protocol to transfer e-mail from the PCA 214 to the mail sender 210. Other known protocols could also be used on path 218. The PCA 214 also transfers data via path 224 to the channels file 212. This data is transferred using the File Transfer Protocol (“FTP”) along path 224. The PCA 214 also has a User Channel Database (“UCDB”) 226, which is described below.
Within the user machine 206 is a mail client 228. In a preferred embodiment, the mail client 228 may be implemented with the Netscape Mail Client and Browser available from Netscape Communications Corp. Of course, other well-known mail clients could also be used. The mail client 228 communicates with the PCA 214 via paths 230 and 232. Path 230 is used for receiving e-mail from the PCA 214 using the POP3 protocol. Path 232 is used for sending e-mail from the mail client 228 to the PCA 214 using the SMTP protocol.
Also within the user machine 206 is a Web browser 234. In a preferred embodiment, the Web browser 234 could be implemented with the Netscape Navigator browser provided by Netscape Communications Corp. The Web browser 234 is used to administer the PCA 214 including the UCDB 226. The Web browser 234 communicates with the PCA 214 along path 236 using the Hypertext Transfer Protocol (“HTTP”), although other known protocols may also be used.
Referring to FIG. 2, conceptually, the PCA 214 acts as an e-mail proxy, sitting between the user's mail client 228 and the mail server 202. Thus, all incoming and outgoing messages pass through the PCA 214, which uses appropriate protocols as discussed above to interact with the mail client 228 and mail server 202. This positioning allows the PCA 214 to autonomously perform various bookkeeping functions, thereby shielding the user from them.
The user channel database (UCDB) 226 primarily records two mappings, the channel map and the correspondent address map. The channel map associates each correspondent with the channel on which the user expects to receive mail from that correspondent. The correspondent-address map associates each correspondent's user and host names with the channel ID (if one exists) on which the user is allowed to send to the correspondent.
The UCDB 226 (or 226a) is conceptually illustrated in FIG. 3. The headings in each column are not actually stored in the database 226, but are provided in FIG. 3 for illustrative purposes. For each correspondent address 302, the UCDB 226 may have one or more of the following entries: own channel 304, correspondent channel 306, own key 308, and correspondent key 310. A correspondent is simply another e-mail user that the user desires to send to or receive mail from. The correspondent address 302 is the standard e-mail address of the correspondent. The own channel 304 is the channel ID 110 used for the correspondent to send e-mail to the user. The correspondent channel 306 is the channel ID 110 that must be used by the user to send e-mail to the correspondent. The own key 308 is a key assigned by the user that is necessary to allow certain functions to be performed. The correspondent key 310 is a key assigned by the correspondent, which is also necessary to allow certain functions to be performed. All of this information is placed in the UCDB 226 by the PCA 214 as it interacts with the mail server 202 and the user machine 206.
Referring now to FIG. 4, a conceptual diagram of the channels file 212 is illustrated. The heading on the column “Open Channels” is illustrative only, and such a heading is not actually stored in the channels file 212. The channels file 212 has a list of channels 401 that have been opened by the user. Opening channels may be accomplished with a user interface. In the example shown in FIG. 4, the first channel listed is “1QXR7112PH”. These channels are checked by the modified Sendmail program when the mail receiver 208 receives a message. The channels file 212 is updated regularly by the PCA 214 from information that has been entered in the UCDB 226. This information is stored in the own channel field 304 of the UCDB, as shown in FIG. 3.
Web-based e-mail services have recently become available for providing a mailbox address and mailbox functions through a server interacting with the client entirely through HTML protocol. Such an arrangement permits an email user to interact with the mail server from any client machine with a browser. Message composition, incoming message display and directory displays are transacted between client and server through HTML pages.
A typical Web-based mail server system, as illustrated in FIG. 5, includes a mail server 504 communicating with a user machine 500 running client software such as browser 501. Communication between the server 504 and user machine 500 is via HTTP protocol 502 transmitted over a network 503 such as the Internet or another public or private computer network.
E-mail messages to recipients (path 551) and from senders (path 550) are transmitted via the network 503 using SMTP protocol or another protocol suitable for mail transfer. Those messages are communicated with the user machine 500 via HTTP protocol through the network 503.
The Web-based mail server 504 contains a mail server portion 506 and a network interface layer 505. The mail server portion 506 includes an incoming message receiver 541 for receiving mail from the network 503, and an outgoing message queue and sender 542 for transmitting outgoing mail. Both the incoming message receiver 541 and outgoing message queue and sender 542 use SMTP protocol in sending and receiving mail messages to and from the network 503. A message store 540 in the mail server portion 506 provides file storage for received messages. The received messages are transferred directly (path 545) to the message store upon receipt.
The network interface layer 505 of the Web-based mail server 504 contains a series of HTML web pages for communicating with the user via browser software on the user machine. For example, the interface layer contains a message composition page 520 that may be presented via HTTP protocol through the network 503 to a user for composing a message. The page contains fields for the address of the message recipient, the subject of the message, message attachments and the message text. To compose a message, a user places information in the HTML fields as necessary and transmits the page with the additional information to the Web-based mail server 504 via HTTP protocol through the network 503. The network interface layer 505 recognizes the information contained in the fields of an incoming message composition page 520, formats the information for transfer via SMTP protocol, and forwards the information (path 525) to the outgoing message queue and sender 542.
Similarly, an in-box page 521 is provided for communication of the contents of the message store 540 to the user via the network 503. Information is transferred via HTTP protocol between the inbox page 521 and the message store 540 via path 544. An in-box page may be transmitted to the user containing, for example, a list of the subject fields, senders and receipt dates for all messages in the in-box file of the message store. Unread messages are typically highlighted in the list to be brought to the user's attention. After a message is read, the user may use administrative controls of the HTML Web pages to delete the message from the message store or move the message from the in-box file to another file within the message store such as a subject matter file.
When a user wishes to read a message from the message store, the user requests that a message display page 522 containing the content of a particular message be transmitted to the user machine. The message contents are retrieved from the message store 540 via path 543 and are placed in appropriate fields of the HTML message display page 522 for transmission to the user machine 500.
In each case, because all information transferred between the user machine 500 and the Web-based mail server 504 utilizes HTTP protocol and is embedded within Web pages readable by a standard browser, no mail client is required at the user machine. Instead, the user may access her mail through any machine having a browser.